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I. INTRODUCTION 



A. BACKGROUND 

Electronic assistance to office workers and the result- 
ing productivity increases have risen dramatically in the 
past two decades. Even the early I970's products, such as 
the IBM magnetic card typewriters, enabled workers to 
vastly improve both the quantity and quality of their efforts. 
The largest gains, however, resulted from the introduction 
of affordable microcomputers. Microcomputers in the office 
environment provided seemingly endless possibilities, such 
as word processing, data processing, information storage, 
message/letter routing via networks, facility for automated 
computations, integration of multiple office functions, 
graphical displays, and numerous others. In fact, office 
workers discovered that one of the marvels of microcomputers 
is that every use of a micro prompts a ’’wouldn' t- it-be-nice- if 
for other users. 

The challenge to meet these "enhanced capability" desires 
was met with gusto by computer programmers -- there are now 
thousands of applications programs in the marketplace to 
meet almost any need. However, since they were written in 
response to specific needs and desires, almost all of these 
programs share a common deficiency: they are too specific 
to be generally useful. Sophisticated word processors 
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cannot handle spreadsheet applications. Simple, menu-driven 
programs are annoyingly tedious to experienced users. 
Integrated packages lack sophistication in all areas. 

B. MOTIVATION 

One area that provides good example o£ the wide range 
o£ capabilities o£ applications-based programs (and the 
motivation £or this thesis) is that o£ database management 
systems. They cover the spectrum £rom very easy to use 
(but very limited in complex querying capability) to very 
power£ul (but too di££icult £or the novice user). While any 
one o£ these programs might be ideal in a particular situa- 
tion, any change in the environment necessitates a change 
o£ systems or an extensive training program. These changes 
might be prohibitively expensive in terms o£ time, money, 
or both, and should not be necessary. "Wouldn ' t - it -be -nice - 
i£” there was a system that was capable o£ satis£ying both 
needs? There will be. 

Be£ore attempting to design such a system, we must 
address two major areas o£ consideration: 1) the needs o£ 
the user, and 2) the requirements o£ the program to meet 
those needs. These areas will be addressed directly here, 
and indirectly throughout the remainder o£ this thesis. 

1 . The Needs o£ the User . 

General requirements £or o££ice workers are covered 
expressly in (LAR 84), and less £ormal approaches in (WON 82), 
(WU 85), and (ZLO 77) also address user needs. Following 
is a consolidation o£ the ideas expressed in those articles. 
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a. Information must be presented in the user's 
view. It must be presented in a form that is natural and 
familiar to the user, or he will never be comfortable 
with the system- -it will always remain somewhat magical 
(and not to be trusted completely). 

b. Memorization requirements must be minimized. 

Most keywords and interaction procedures are arbitarily 
assigned, and requiring the user to memorize them intro- 
duces a new abstraction that is not natural for him to 
accept. This concept should be applied to several areas: 

(1) Database. (LAR 84) states "the office worker should 
not need to remember the logical structure of the 
database ... the system should display this information"; 

(2) Query language. Whether the language is composed of 
words, pictures, or some combination of those, the 
user should be able to quickly gain an intuition 
about the meaning of the symbols; 

(3) Query formulation. The formulation process should 
coincide with the user's thought process, so the 
program must include the capability for the user to 
formulate a query in a piecemeal fashion. 

c. Training time must be minimized. While there 
must be some training for any non-trivial program, an 
excessive training time requirement will exclude some users 
(who simply cannot invest that amount of time) and will 
discourage those who do attempt the training program. 

d. The possibility of erroneous input must be 
minimized. There are two types of errors which can be 
easily detected (and therefore avoided): 1) an inappropriate 
command (i.e. a normally valid command at an inappropriate 
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time in program execution), and 2) a mistyped command 
(i.e. improper spelling or invalid format). Taking action 
to avoid these two errors will not assure the user a mis- 
take-free session with the program, but it will go far to 
increase the user's confidence by eliminating major prob- 
lems caused by trivial errors. 

e. Feedback must be provided. A good example of 
this (without examining a specific program) is the capability 
to display intermediate results during the query process. 
While it is not desirable to overburdent the user with 
informatin (don't make this display mandatory), he should 

be able to access it if desired to verify the correctness 
of his query. Another benefit of feedback is that it 
encourages experimentation- -it answers the "what-would- 
happen-if-I-asked-this" question. 

f. Help must be provided. User help can take on 
many forms, such as menus, subject directories, help 
messages, error messages, structure displays, screen layout, 
intermediate result displays, input prompts, and many 
others. It is the responsibility of the designer to pro- 
vide sufficient help to the novice user without forcing 
unnecessary help onto the sophisticated user (WU 85). 

g. It must be capable. Though all other goals 
may make the user comfortable and confident, they are all 
for naught if the user cannot extract the required informa- 
tion. He must be able to perform a wide range of activities. 



9 



from simple data/structure viewing to the formulation of 
complex queries. 

2 . The Requirements of a Program to Meet User Needs. 

The characteristics of such a prqgram (or, more 
specifically, a database interface package) are addressed 
in (WU 85). Those characteristics are reiterated here, 
along with explanatory comments and the user requirements 
(described above) that they satisfy. 

a. It must be descriptive. This includes both 
the kinds of data stored and their relationships. This 
characteristic satisfies requirements B.l)(a), B.l)(b), 
B.l)(c), and B.l)(f). 

b. It must be powerful. If the information is con- 
tained in the database, the user must be able to extract 
it, regardless of the complexity of the query. This 
characteristic satisfies requirement B.l)(g). 

c. It must be easy to learn. Many users of the 
program will be novices unfamiliar with database terminology, 
and the designer is challenged to produce a program which 
can be quickly learned (interactive tutorials are often 
helpful in this process). Designing a program with this 
characteristic will necessarily satisfy requirements B.l(a) 

B. l(b), B.l(d), B.l(e), B.l(f) and B.l(g). 

C. POSSIBILITIES 

We now have some solid requirements to begin a program 
design. However, there still remain several questions that 
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must be answered. These questions present themselves in a 
sequential nature, so let us now address them in that man- 
ner and explore the possibilities. 

1 . Has the Problem Already Been Solved ? 

The answer is "no". While there are many database 
programs available (some o£ which will be discussed in 
Section D) , none o£ them satis£y all the requirements £or 
the user and the program. The biggest trade-o££ in exist- 
ing programs is the ease o£ use as opposed to power. 

2 . Is an Entire New Program Required? 

Probably. While it might be possible to modi£y 
existing programs to eliminate some o£ the disadvantages 
and meet more o£ the requirements, there would inevitably 
remain some inappropriate characteristics which are either 
impossible or not cost e££ective to remove. It would be 
much better to incorporate the positive characteristics o£ 
many such programs into a new one while avoiding the negatives. 

3 . Will an Inter£ace Program Meet Our Needs? 

Yes. The only caution here is to ensure that the 
underlying program/query language is capable. A power£ul 
program can be made easy to use: an inherently weak program 
cannot be made power£ul without extensive, £undamental 
changes . 



4 . What Type 0£ Inter£ace Do We Want To Use? 

As discussed in (WU 86), there are three ways the 
user interacts with a database management system: the 
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creation of the database, the manipulation of data, and the 
development of applications programs. He goes on to dis- 
cuss several existing interface methods, such as natural 
language interface (BOG 84, COD 74, HEN 77, WAL 78), 
modified query language interface (KOR 84, MAC 85), graphics 
interface (HER 80, EAR 84, MCD 74, STO 82, WON 84, ZLO 77), 
fourth generation languages, and f ill - in- the - form program- 
ming (ROW 85). None of these existing interfaces, however, 
address all three types of user interaction. What is needed 
is a single, unified interface which will enable the user 
to accomplish all his activities within one environment. 

The interface method which presents the greatest potential 
for this is the graphics interface. 

5 . Why a Graphics Interface ? 

(RAE 85) presents an excellent discussion of the 
advantages of using graphics in programming, and those 
points can be directly related to program users. Some of 
those advantages are: the random-access nature of text, 
the increased dimension of expressions one can achieve 
with pictures, the higher rate of knowledge transfer through 
pictures, and the increased ability to represent the real 
world through pictures. While it would not be universally 
useful to devise an interface which presents only pictures, 
some combination of pictures and text layed out in a 
graphical representation would achieve the same advantages. 
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D. EARLY WORKS 



The potential for a userful graphics interface has long 
been recognized, as evidenced by the number of graphics 
interfaces developed over the past ten years. Following 
is a brief review of four of these interfaces, using the 
criteria in (WU 85) (described in Section B.2) to judge 
their effectiveness. 

1 . Query-by- Example (QBE) . 

QBE (ZLO 77) was one of the first DBMS graphics 
interfaces. Its philosophy was to minimize the requirements 
(of initial knowledge and memorization) imposed on the user. 
QBE is relationally complete, so users can formulate any 
query that can be expressed in relational algebra or predicate 
calculus; however, "skeletons" (templates) are provided for 
query formulation to alleviate the need for the user to 
know first order predicate calculus. The major problem 
with QBE and similar approaches, such as those reported in 
(LAR 84) and (SUG 84), is that they lack descriptiveness. 

All input and output in QBE is in tabular form, so it is 
difficult for the user to get a good overview of the system 
and relationships of the data, and it is not possible for 
him to easily browse through the data or database schema. 

2 . Spatial Data Management System (SDMS) . 

SDMS (HER 80) is a good example of a program that 
is easy to use, but has limited capability. Data are 
represented in graphical form, and their relationships are 
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determined by their spatial positions in a graphical data 
space. The system was written for novice users, and seems 
to encourage browsing with its "zoom", "unzoom", and "position 
cursor" commands. Simple data retrieval is relatively easy 
with SDMS , but it lacks a simple method to formulate a 
complex query. Therefore, the poser of SDMS is not accessible 
to many users. 

3 . Text, Icon, and Map Browser for Extended Relations 
[TIMBER) . 

TIMBER (STO 82) is described by its author as "a 
user friendly, graphics -oriented browser for a relational 
data base". It provides the same type of browse capabilities 
as SDMS, enhanced by incorporating some of the concepts of 
QBE. Its ability to support icons, maps, text, and normal 
fixed format relations is an improvement over SDMS, but it 
still lacks power and descriptiveness. 

4 . Graphical User Interface for Database Exploration 
(GUIDE) . 

GUIDE (WON 82) is the first graphics interface 
package that attempts to address all the requirements 
described ablve. It is descriptive in that it displays 
the database schema as a network of entity and relationship 
types. It also provides hierarchical subject directories 
to further describe database contents and assist in data 
location. It allows for piecemeal query formulation and 
gives feedback by displaying intermediate results, making 
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complex queries possible. However, some aspects o£ GUIDE 
still hinder its effective use. These include the lack of 
relation browsing capability, the lack of aggregate functions, 
and the use of two different types of diagrams (Entity/ 
Relationship and hierarchical subject directories) during 
program execution. These disadvantages can be major 
hinderances to the novice user. 

E. NEW SYSTEM PROPOSAL 

As we have seen, each of the previous works in graphics 
interfaces addresses one or more of the requirements for 
an effective system. However, none of them satisfactorily 
provides solutions to all requirements. It is the purpose 
of this thesis, as the initial step in the production of a 
useful graphics interface, to introduce and design a system 
to address all requirements of both the user and the program. 

Basic descriptions of such a system are presented in 
(WU 85) and (WU 86). The system is called Graphics 
Language for Accessing Database (GLAD) . Its intent is to 
provide a complete, effective interface devoid of the pre- 
viously discussed disadvantages by incorporating the 
positive characteristics of several earlier works into a 
single, unified interface package. A complete description 
of GLAD characteristics is given in Chapter 2, but let me 
now briefly address how GLAD will satisfy the four require- 
ments for an interface presented in (WU 85). 
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1 . Descriptiveness . 



GLAD will employ a diagrammatic display of the 
database schema. This diagram will be rich in meaning 
because it gives a graphical representation of both the 
entities involved and their relationships, and is applicable 
to all data models. In addition, help facilities will be 
included to describe object names and formats to the user. 

2 . Power . 

glad's querying capability will be based on the 
concepts of QBE. As previously discussed, QBE is relational- 
ly complete, so GLAD will inherit from QBE the ability to 
formulate any query which can be expressed in relational 
algebra or predicate calculus. 

3 . Ease of Learning. 

GLAD will be easy to learn because it employs the 
use of common, easily recognizable symbols to identify 
objects. These symbols are circles, dotted and solid lines, 
and regular, nested and repeated rectables. They will be 
arranged in a natural, sensible manner with the complexity 
of the arrangement corresponding to the complexity of the 
obj ects/relationships . In addition, many help facilities 
will be available to (but not imposed upon) the user. 

4 . Ease of Use. 

GLAD will have many features making it easy to 
use. One of these is a convenient browsing facility with 
its own submenu to allow the user easy access to any area 
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of the database and its information. Another is its 
mechanism for query formulation. The user can formulate 
queries in piecemeal fashion, access intermediate results, 
and combine results in any manner convenient to him. 

Finally, help facilities should quickly alleviate any 
stumbling block the user might encounter. 

F. THESIS ORGANIZATION 

The remainder of this thesis will be organized as 
described below. 

1 . Chapter 2: Specifications . 

This chapter will include informal specifications 
for GLAD, including characteristics, program components, 
menu lay-outs, use of the mouse, design priorities, and 
design hints and guidelines. 

2 . Chapter 3: Design . 

This chapter will be divided into two major 
sections- -architectural design and detailed design. The 
architectural design section will decompose the program 
functions into "black boxes", with emphasis on relationships 
and interfaces. The detailed design section will be a re- 
peated stepwise refinement of those functions until they are 
reduced to a sufficiently low level to be readily imple- 
mented in a programming language (in this case the C Programming 
Language) . 

3 . Chapter 4: Conclusions and Recommendations . 

This chapter will provide the conclusions of the 

author as a result of the design of this program, along with 
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some recommendations to aid/guide further work. These 
recommendations will address the required steps to 
complete the production of this system, and some avenues 
of further research which present themselves during this 
current work. 

Finally, sections will be included for the list of 
references and bibliography. 
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II. SPECIFICATIONS 



A. INTRODUCTION 

This chapter describes GLAD as it is to be designed, 
including its screen presentation, possible user actions, 
data representations, and other characteristics of the 
program. It does not provide requirements in the strict 
sense (FAI 85), because the specifications are not (nor are 
they intended to be) complete. Formal specifications for 
a software project generally provide a means to ensure the 
designers, testers, and customers are in agreement about 
the use and action of the program, provide a basis for 
product validation, and provide a document to assist 
maintenance personnel. In this project, however, there is 
only the design team and the motivation for writing 
"specifications" is to solidify the concepts and general 
operational characteristics of the program in our own minds. 

As such, this chapter might be more appropriately titled 
"GOALS for GLAD". Areas to be addressed include advantages 
of GLAD, basic program component descriptions, exception 
handling, priorities in design, and design hints and guidelines. 

B. ADVANTAGES OF GLAD 

The motivation behind designing this new database manage- 
ment program interface stems directly from the disadvantages 
found in earlier works in this field. Several such works 
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were discussed in Chapter 1, so we will confine our dis- 
cussions here to the advantages we will achieve with GLAD. 
1. Ease of Use. 



In today’s environment, many database management 
programs are used by those who are either unfamiliar with 
computers in general or are not experienced in database 
terminology. This necessitates a program which can show 
the user what he needs to know and what he needs to do 
without requiring him to invest excessive time to learn 
database terminology or a query language. At the same time, 
ease of use implies that a user should be able to formulate 
complex queries in a simple, straightforward manner. GLAD 
will accomplish ease of use by: 

(a) Presenting the database schema in a graphical form, 
as shown in Figure 2.1. This will provide the user 
an immediate overview of the database and its re- 
lationships, which will benefit the novice by giving 
him an intuitive feel for the relationships in the 
database, and the experienced user by showing all 
top-level aggregates and their associations. It also 
serves as a data dictionary, since the user can easily 
examine the format or contents of an object. 
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Figure 2.1 Graphical Representation of Data 
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(b) Encouraging relation browsing. The graphical 
presentation of the data and the simple use of 
the three-button mouse make it very easy for any 

user to browse any object or relation in the database. 

(c) Using similar techniques for all user actions. The 
user will be able to press the same buttons on the 
mouse for similar functions, whether he is viewing 
the database or formulating queries. For example, 
the center button will be used for displaying a pop- 
up menu and selecting an action both to query the 
database and to print the results of the query. 

(d) Making it simple to change levels of abstraction. 

By a single press on a mouse button, the user can 
change from the display of all aggregates to showing 
the attributes (sub-objects) or members of a single 
ob j ect . 

2 . Power . 

The most essential element in any database program 
is the ability to extract the required information from it. 
GLAD will use graphics to assist the user in query formula- 
tion and will pattern its querying capability after QBE 
(ZLO 77), which will ensure it is capable of any query 
which can be expressed in relational algebra or predicate 
calculus . 

3 . Descript iveness . 

This entails both displaying all data and their 
relationships and assisting the user by describing his 
options for actions and their consequences. GLAD will 
achieve these by providing: 

(a) Aggregation. This is a grouping of objects or sub- 
objects. The user will see aggregates as object 
names enclosed in rectangles, and can view the sub- 
objects by EXPANDing the object (see Figure 2.2). 
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Figure 2.2 Object Representation 

(b) Generalization. This is a grouping of objects by 
their general category. The user will see generaliza- 
tion names enclosed in double (nested) rectangles, 

and can view the individual objects by EXPANDing the 
general i za t ion . 

(c) Classification. Each item in the database will be 
described (classified) as a piece of information 
about an object. These data items will be defined 
as members of an object and can be viewed by select- 
ing the LIST MEMBER command (from the pop-up menu 

on the mouse or the menu along the top border). 

(d) Relationships. Relationships between objects in 
GLAD are broken down into four categories (see Figure 
2.3) : 

(1) Relation. This is a basic association between 
two objects as defined by the user (i.e. identical 
object or sub-object names that provide a link 
between the objects). A relation is indicated 

by a solid line connecting the two objects (see 
Figure 2.3a). 

(2) Partial relation. This is a relation where, 
given two objects A and B, 1) a sub-object of 
A is related to B, 2) a sub-object of B is 
related to A, or 3) a sub-object of A is related 
to a sub-object of B. A partial relation is 
indicated by a dotted line connecting the 
objects (see Figure 2.3b). 
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Figure 2.3a Relation 



Figure 2.3b Partial Relation 




Figure 2.3c Disjunctive 
Relat ion 




Figure 2.3d Recursive 
Relation 



Figure 2.3 Relation Representation 

(3) Disjunctive Relation. This is a relationship 
between one object and one of multiple other 
objects. A disjunctive relation is indicated by 
a solid line connecting the first object to 
each of the other objects with a circle at the 
end of the lines terminating at the first object 
(see F igure 2.3c). 

(4) Recursive Relation. This is a situation in 
which two specialized objects within the same 
generalized object are related to each other. 
Recursive relations are represented by a re- 
peated rectangle (see Figure 2.3d) and each 
association in the recursive relation is in- 
dicated by a semi-circular solid line beginning 
and ending at the object. 

(e) Flelp. On each menu level, there will be provided 
[lELP selection which will describe the actions the 
user may take at that point and the consequences 
resulting from each. 
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4 . Ease of Learning. 

This generally follows from (1), with the addition 
that the program must provide sufficient assistance so that 
a novice can quickly acquire the ability to command those 
actions necessary for him to extract his required informa- 
tion. This is provided by the graphical display of the 
data, the permanent menu displayed along the top border, 
the use of the mouse, and easy- to-access help. 

C. BASIC PROGRAM COMPONENT DESCRIPTIONS 

This section will provide definitions of terms, 
descriptions and lay-out of menus, screen display character- 
istics, program flow, and use of the mouse. It is not 
intended to be intractible, but will provide guidelines for 
the design phase. 

1 . Definition of Terms. 

a. Object--any single piece of information or 
collection of information which is intended to be recognized 
as a single entity. 

b. Atomic Object--a single piece of information 
which represents only one system-or user-defined base object 
(string, number, enumeration, subrange, and boolean). 

c. Agregate object--a specific collection of one 

or more (sub)obj ects . 

d. Generalized Object--a collection of objects 
grouped together by a common category or subject. 
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e. Specialized object--any one of the grouping in 
a generalized object. 

2 . Descriptions and Lay-outs of Menus. 

GLAD will provide menus to cover all user actions. 
They will be heirarchically structured, and will be ac- 
cessed in two ways: by selecting one of the items listed 
on the menu along the top border and by pressing the center 
button on the mouse and selecting one of the items on the 
menu which pops up. There are three main functional menus 
in GLAD: the Administration Menu, the Browse Menu, and the 
Execution Menu. The Administration Menu will be displayed 
when the program starts, the Browse Menu is accessed by 
selecting EXPLORE, and the Execution Menu is accessed by 
selecting QUERY. In addition, several items on these menus 
will have their own short sub-menus, which will appear be- 
low them (and can be accessed by the mouse when appropriate. 
Only the current main menu will be displayed, and others 
will appear when an appropriate selection is made on the 
current level. Menu items are selected by pointing to 
them with the mouse pointed and pressing the right (select) 
button, or by displaying the pop-up menu by pressing the 
center mouse button and keeping it depressed while you roll 
the mouse down until the correct choice is highlighted and 
releasing it. Menu items are de-selected (i.e. results are 
erased and screen is rewritten by re-selecting an already 
active (selected) item. All prompts to the user will be 
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placed on a Command Line located immediately below the 
top border menu. 

a. Administration Menu (see Figure 2.4), This 
menu will be displayed immediately when-the program starts, 
and provides the user with his initial choices for manipu- 
lating the database. Menu items include: 

(1) OPEN--this option opens the database to be used by 
prompting the user to enter the database name. 

When it receives the name, it causes the initial 
screen display showing object rectangles, names, 
and relationship connecting lines. 

(2) CLOSE- -this option closes the database by ensuring 
all files are closed. The user is queried to 
save or abandon any open files. This can be done 
at any time during the execution of the program, 
providing the user the ability to ensure all prior 
work is complete before continuing or quitting, 

(3) EXPLORE- - this option allows the user to view and 
query the database. While no database manipulation 
is performed as a direct result of choosing EXPLORE, 
the menu is changed to the Browse Menu (described 
later), and the level of abstraction is changed so 
that data manipulation can be done. 

(4) SET-UP--this option allows the user to alter default 
values in the program. For example, he can instruct 
the program to SHOW RESULTS each time they are 
created, or he can have the results DESCRIBEd auto- 
matically , 

(5) HELP--this option provides help with all Administra- 
tion Menu items. It describes each of the menu items, 
actions which will be performed when selected, and 
associated sub-menus. 

(6) QUIT--this option exits the database program and re- 
turns the system's prompt. If there are any open 
files, it provides a prompt to the user to CLOSE 
first or QUIT abandoning open files. 
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Figure 2.4 Administration Menu 
b. Browse Menu (accessed by selecting EXPLORE on 
the Administration Menu) (see Figure 2.5). This menu pro- 
vides options to the user to manipulate the database on 
the "aggregate object" level. Items provided in this menu 
are : 

(1) DESCRIBE- -this option provides the user with a 

def inition-type description of an object. The object 
and all sub-object names are displayed with their 
associated data types, and all relations 1 inking this 
object with others are listed. If the object is 
a generalized object, its associated specific objects 
are displayed with their data types. 

(2) QUERY--this option is similar to the EXPLORE menu 
item in that no direct data manipulation is performed 
when it is selected. It does, however, change the 
level of abstraction and displays the Execution Menu 
to allow the user to query the database. 

(3) UPDATE--this option allows the user to add to or 
change the information in an object. It provides an 
object skeleton (with current values if the mouse 
pointing to an object) and a sub-menu to prompt the 
user for pertinent information. 

(4) PRINT--this option allov>/s the user to print portions 
of the database or results of a query. In addition, 
there is provided a means to "screen dump" to allow 
the user to make a hardcopy of the graphical repre- 
sentation of any screen display during the execution 
of the program. These options are provided in 
PRINT'S sub-menu. 
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(5) EXPAND--this option is similar to DESCRIBE except 
that it is intended to be used in a "browse mode", 
and just shows the atomic sub-objects of the se- 
lected object. It is important to note here that 
non-atomic sub-objects are not displayed: they are 
the items which link the object to other objects 
and are not important to the object definition. 

These are only displayed during the UPDATE operation. 

(6) LIST MEMBER--this option is used to display an in- 
stantiation of an object or sub-object, listing 
current information contained in it. 

( 7 ) CENTER--this option will center the display around 
the object pointed to by the mouse pointer. If no 
object is being pointed to, the user is prompted 

for the object name around which to center the display. 

(8) HELP--this option is identical to the HELP option 
in the Administration Menu, except that it covers 
items in the Browse Menu. 

(9) QUIT--this option returns the user to the Administra- 
tion Menu. If there are any open files or queries, 
it will prompt the user to complete the action be- 
fore the return is executed. 



des - 
scribe 



que ry 



update 
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expand 
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center 
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quit 



Figure 2.5 Browse Menu 

c. Execution Me-nu (accessed by selecting QUERY on 
the Browse Menu) (see Figure 2.6). The functions described 
in this menu demonstrates the real strength of GLAD. They 
allow the user to specify objects and sub-objects, create 
results of queries, and display, print, combine, and save 
those results. The Execution Menu items are: 
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(1) SAVE RESULT- -this option provides to the user a 
permanent record of process used to achieve his 
result. This is done by saving to disk a file (user 
is prompted for filename) containing the process. 
This process can be called later by the user by the 
use of a "program box" (which will be designed and 
implemented later) . 

(2) SHOW RESULT--this option is identical to the LIST 
MEMBER command, except that it acts on the result 
pointed to by the mouse pointer. By requiring the 
mouse to point to the result, the user can review 
any of several results he has created. It should 
be noted here that SHOW RESULT causes the actual 
result formulation: before this time, only the 
process for result formulation is saved. 

(3) CLEAR RESULT--this option simply erases the process 
which creates the result pointed to by the mouse 
pointer. This enables the user to "take back" 
erroneous query formulations, and eliminate old 
results before proceeding with new queries. 

(4) CREATE RESULT--this option tells the program that 
all specifications have been made and the user is 
ready to form the result. The result formulation 
is not actually performed at this time (since it is 
time-consuming and may not ever be required), but 
the process is saved to be used if needed. When 
the process has been saved, an icon (rounded-corner 
rectangle) is placed at the bottom of the screen 
labeled RESULT X, and all rectangles associated with 
the query are identically shaded (see Figure 2.7). 

(5) COPY RESULT- -this option makes an identical copy of 
the result process pointed to by the mouse pointer. 
It is placed adjacent to the copied result at the 
bottom of the screen and is labeled RESULT X COPY. 

By performing the COPY RESULT, the user is able to 
experiment with several combinations of results 
without destroying the original contents of the 
individual result processes. 

(6) COMBINE RESULT- -this option performs a join of two 
or more intermediate results. If there are only 
two results present, the join is done immediately. 

If there are more than two, the user is prompted for 
the names of the results to be joined. When the 
join is completed, the individual result processes 
are erased and a new result process is placed at the 
bottom of the screen with all associated rectangles 
(from the previous results) identically shaded (see 
Figure 2.8). 
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Figure 2,6 Execution Menu. 




Figure 2.7 Create Result. 
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Figure 2.8a Before Combine Figure 2.8b After Combine 
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Figure 2.8 Combine Result 

(7) SPECIFY- -this option creates an "object skeleton" 
for the object pointed to by the mouse pointer. 

This skeleton contains the name of the object and 
all associated fields in table-name format, and an 
area below these for query specification (see Figure 
2.9) . 

(8) DESCRI BE- -this option provides a description of the 
result pointed to by the mouse pointer. Included 
are the name of the queried object and the specifica- 
tions entered by the user. This description is 
placed immediately below the result. It remains on 
the screen until the result is CLEARed or COMBINEd 
(see Figure 2.10) . 
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Figure 2.9 Specify Skeleton. 
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Figure 2.10 Describe Result. 

(9) CREATE REPORT FORM--this option allows the user to 
format a report to be printed (and will apply to 
both objects and results). He is given a skeleton 
in which he must provide the form name, report title, 
and field names, data types, and sizes. The field 
names are especially important because when the re- 
port form is used, type-checking will be accomplished 
to ensure those names match the sub-object names in 
the object chosen to be printed. 
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( 10 ) 



HELP--this option is identical to the former HELP 
options except that it acts on Execution Menu 
items . 

(11) QUIT--this option returns the user to the Browse 
Menu. If there are any open queries, it prompts 
the user to either complete or abandon those actions 
before QUIT is executed. 

d. Update Sub-Menu (Execution Level) (see Figure 
2.11). This sub-menu provides a means for the user to 
enter or update information and relations. This ability 
applies to all actions normally performed in the creation 
of an object/relation, and the capability to change things 
such as object names, attributes, values, and relations. 

Access to this ability must be limited to specific users 
in order to preserve the integrity of the system, and that 
access will probably be determined by the database administra- 
tor. (The specifics of this process have not yet been de- 
termined. The following description assumes complete access.) 
If the mouse pointer is on an object, the selected object 
is expanded to an object skeleton, where the user can add 
to or change any part of the object. If not, the user is 
prompted to determine if he wants to create a link or an 
object. If he chooses an object, a blank object skeleton 
is generated where the user can identify names and informa- 
tion. If he chooses link, he is prompted for objects to be 
linked and the link field. Items included on this menu are: 

(1) SAVE--this option allows the user to save his changes 
or additions. If he has created a new object, it 
will not yet be linked to any other, and will be 
displayed as an object, except that it will show no 
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links. If he has created or changed a link, the 
screen presentation will be altered to show this. 

(2) ABANDON- -this option allows the user to exit UPDATE 
without any changes or additions made. 




Figure 2.11 UPDATE Sub -Menu, 
e. Print Sub-Menu (Execution level) (see Figure 
2.12). This sub-menu allows the user to obtain a hardcopy 
of any object (including results) or screen display during 
the execution of the program. Items on its sub-menu 
include : 

(1) SCREEN DUMP--this option prints the entire screen 
with the exception of menu items and user prompts, 
to enable the user to presentations and records of 
his work. 

(2) PRINT OBJECT--this option prompts the user for the 
name of the object (which can be RESULT X) and sends 
it to print. It will be printed in tabular form 
with the name of the object displayed as the report 
title. 

(3) PRINT REPORT--this option allows the user to print 
a previously formatted report. He will be required 
to enter two parameters; 1) the name of the report 
form. He can either type the name or depress the 
center mouse button and roll it down until the cor- 
rect choice is highlighted and release it, and 2) 
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the object (including results) to be printed. Again, 
he can either type the name of the object or position 
the mouse over the object and press the select (right) 
button. These inputs can be in either order, but 
the second choice will be type-checked against the 
first to ensure the field names to be printed in the 
report actually exist in the object. 




Figure 2.12 PRINT Sub-Menu. 

5 . Screen Display Characteristics. 

Since GLAD is being written to be run on a graphics 
terminal, several advantages are gained in the screen dis- 
play. The basic display, as shown in Figure 2.13, is as 
fo 1 lows : 

(1) All major program components are placed in windows. 
Included are menus, ob j ect - rel at ion layout, and 
menu operations (e.g. LIST MEMBER, SELECT). 

(2) All windows will include elevator bars to show the 
user where he is in relation to the entire window 
if it does not all fit into the allotted screen 
space . 

(3) Any window size can be changed at any time by press- 
ing the left (drag) button on the mouse and expanding 
or contracting the elastic rectangle. When the 
button is released, the amount of information dis- 
played will be altered to accommodate that window 
size. 
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Describe/Show Result Window 



4 • Program Flow. 

Basic program flow has been discussed at some 

length and the basic control flow diagram is shown in 

Figure 2.14. In amplification of those two sources, the 

following lists the steps required to operate the program. 

or execute the program. This will present the 
Administration Menu and object display windows. 



( 2 ) 



select EXPLORE to 

enter the Browse Menu. 



OHFRY^r ^ ^ ion browsing and/or select 

QUERY to enter the Execution Menu. 



( 4 ) 



Do database querying at this level. Create and 

save results, then return to higher-level menus 
by selecting QUIT. nitnus 




Figure 2.14 Basic Control Flow Diagram. 
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5, Use of the Mouse. 



A three-button mouse is required for the operation 
of this program. Its use is as follows: 

(1) Button 1. This is the "drag" button to be used for 
adjusting window sizes. To alter the size of a 
window, put the mouse pointer on the upper right 
corner of the window and depress button 1 (the left 
button). Keeping the button depressed, roll the 
mouse in the desired direction until the elastic 
window is the right size. Then release the button, 
and the window will expand/contract to the new size 
and the amount of information displayed (and the 
elevator bars) will be altered accordingly. 

(2) Button 2. This is the "menu" button to be used for 
displaying and selecting menu items. When button 

2 (the center button) is depressed, the same menu 
as appears along the top border will pop up. Keep- 
ing the button depressed, roll the mouse down until 
the desired option is highlighted. Then release the 
button, selecting the highlighted option. Repeating 
this procedure on a previously selected item will 
de-select it, clearing the operation and rewriting 
the screen. 

(3) Button 3. This is the "select" button to be used 
for selecting an item. Roll the mouse until the 
pointer rests on the desired item, then press 

button 3 (the right button) . Repeating this procedure 
on a previously selected item will de-select it, 
clearing the operation and rewriting the screen. 

D. EXCEPTION HANDLING 

This selection will not be all-inclusive in that we 
cannot at this time foresee all possible situations which 
might present "fatal errors". However, several areas can 
be discussed that will contribute significantly to con- 
sistency and "friendliness" in program execution. The de- 
sign should incorporate the following procedures and use 
them as conceptual guidance in other exception handling 
decisions that might be required. 
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(1) In general, test specifically for acceptable input 
rather than testing for specific erroneous input. 

For example, let's look at the situation in which 

we are waiting for a REPORT FORM object to be selected. 
Rather than deciding how to handle a mouse click in 
the describe window, or a mouse click outside all 
windows, etc., ask "is the mouse .positioned on an 
object?" If it is not, then it is an error, regard- 
less of where the mouse was when it clicked. 

(2) When an error has been detected, prompt the user for 
the correct input by printing a "reminder" along 
the bottom line of the screen (in inverse video). 

In the example above, the prompt might read "position 
mouse over desired object and click right button, 
or type object name". 

(3) In situations where user confusion might be antici- 
pated, look for specific errors that would enable 
the program to assist the user. In the example 
above, if the user selected another menu item when 
the object selection was expected, a reminder along 
the bottom of the screen might read "operation pend- 
ing... must complete or de-select previous operation". 

E. PRIORITIES IN DESIGN 

The design for GLAD will be accomplished in two 
distinct stages. First will be the preliminary (or archi- 
tectural) design. This entails decomposing the program 
into "black box" modules according to functions to be ac- 
complished. It will concentrate on the properties of the 
modules and their interconnnections . The second stage of 
design will be a stepwise refinement of the abstractions 
introduced in the first stage. The completion of design 

will be defined as the point at which all modules are 
written in low-level algorithmic language appropriate for 
direct implementation in a programming language (in this 
case, the C programming language). 
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Accomplishing the design as described above supports 
a consistent, organized, hierarchical program structure. 
However, it does not lend itself well to assigning 
priorities to designing particular program components 
before others. In general, we do not desire to assign 
such priorities , but there are several areas which could 
be addressed that would enable early completion of a proto- 
type of the program if it is deemed necessary. These areas 
include : 

(1) Screen display. Program components such as genera- 
tion of windows, use of elevator bars, and arrange- 
ment of windows on the screen are important to the 
program, but are not dependent upon the data structures 
or other aspects of the program. Therefore, imple- 
mentation work on these components could begin as 

soon as the exact screen layout is designed. 

(2) Use of the mouse. Again, the use of the mouse will 
not depend upon the details of the rest of the pro- 
gram, but only needs to know the general layout of 
pop-up menus and the use of each of the buttons. 

(3) File handling. This aspect of the program is general 
in nature and is identical to any other in that 
files will be opened, appended, edited, deleted, and 
saved. The modules dealing with these functions 
could be implemented at any time. 

F. DESIGN HINTS AND GUIDELINES. 

Many aspects of the design have already been addressed 
in these specifications, so this section is intended to 
augment rather than supercede any previous design discussion. 
The following comments will assist in the design phase by 
providing the "policy" for program characteristics and user 
friendliness . 



40 



(1) Always design to allow the user to escape from any 
action before it is initiated. The user should 
always be able to press the "escape key" (actual 
keystroke not yet determined) to erase an operation 
before it begins. Let's look at CREATE RESULT for 
an example. In this case, the user will have 
selected the modules and determined the conditions, 
but may change his mind before selecting CREATE 
RESULT. Pressing the "escape key" will cancel all 
current SPECIFYs and return to the current menu. 

This ability will greatly enhance the user friendli- 
ness of the program to novice users, and will bene- 
fit sophisticated users as well. 

(2) Do not make the user a slave to the program by making 
him memorize arbitrary formats. For example, the 
program may store all REPORT FORM files as a filename 
ending with ".form”, but do not make the user remember 
to put ".form" at the end of all such filenames. 
Rather, make the program append it to the name sup- 
plied by the user. In addition, when printing these 
filenames in the CREATE REPORT FORM pop-up menu, 

take the ".form" off to avoid any user confusion. 

(3) Do not force unnecessary information upon the user. 

It might confuse the novice user, and it would 
definitely annoy the sophisticated user . A good 
example of this point is the situation described in 
the "Exception Handling" section. When an error has 
been detected, it is appropriate to remind the user 
of what type of input is expected. Providing this 
reminder before that time could be both distracting 
and discomforting. 
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III. DESIGN 



A. METHODOLOGY 

The design phase of the life-cycle of a computer program 
is one which is of utmost importance. The reason is that 
its usefulness is directly related to the value placed on 
it by the software development team. It is sometimes poorly 
performed or omitted entirely. When this occurs, the im- 
plementation is much more difficult and the maintenance 
phase must depend entirely on the information supplied in 
the code by the implementors . 

Conversely, a good design greatly simplifies implementa- 
tion and facilitates maintenance by providing documentation 
and considering modern programming practices (as described 
in (FAI 85)). The benefits available from a good design 
of GLAD are even greater, since the implementor will not 
have the advantage of communications with the designer. 

For this reason, it is very important to find a representa- 
tion which will be well-documented and easily understand- 
able. 

The design notation chose for this project is Hierarchy- 
Input - Process -Output (HIPO) diagrams. Some of the advantages 
HIPO provides include: 

1 . Improved Documentation . 

Since HIPO is a multi-stage process, both the function 
and method of each module are well -explained . The advantage 
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is that the designer is not required to generate this 
documentation as a separate step: it is inherent to the 
process of designing the overview and detail diagrams. 

2 . Application of Modern Programming Techniques. 

HIPO is a top-down design approach, which lends 

iteself well to the considerations of modern practices, 
such as choosing an efficient design technique and other 
design considerations (such as coupling and cohesion (YOU 
79 )). 

3 . Descriptions Vice Algorithms. 

This can also be a disadvantage since the design 
cannot be mindlessly implemented, but it allows the imple- 
mentor some freedom in implementation style and techniques. 
Since the implementation will be a follow-on project in 
this case, this HIPO property should prove advantageous. 

B. DESIGN CONSIDERATIONS 

Throughout this (and any other) design activity, many 
choices evolved. Some affected the nature of the program, 
some were "the best of several alternatives”, and some were 
just a matter of style. Since our approach here is top- 
down, all decisions were put off as long as possible (and, 
indeed, many will be made during implementation). Of the 
decisions which were made during design, some are self- 
explanatory and are not discussed in this document. Others 
are minor (perhaps style) decisions, and are addressed in 
the "notes” section of the HIPO diagrams. There are a few. 
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however, which are important to the very nature of the 
program and are explained here. 

C. DESIGN DECISIONS 

Perhaps the most important decision. is whether this 
program will result in a new database management program 
or serve as an interface to an existing program. While 
either decision could be accomplished, we decided to make 
this an interface. However, as discussed in Chapter I, 
we must ensure that the underlying query language is capable. 
The intention is that the implementation will take the 
actions to a certain level of abstraction, then a simple 
adaptive interface could be written that would "translate" 
GLAD'S symbolic instructional words to those of any under- 
lying query language. It is interesting to note, however, 
that the implementation could just as easily be written so 
that the instructions are in a particular query language 
to facilitate maintenance. 

A second "early" design decision was the type of 
modularization that would be used. We decided to break 
the program down into modules that would most closely follow 
the static, hierarchical nature of the program, since that 
would provide modules which are easily recognizable by 
function. In addition, this provides very cohesive modules 
with minimum coupling (again, to make implementation straight 
forward and maintenance easier) . 
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Another important decision involves the user interaction. 
Two aspects of that decision, which will be addressed here, 
are menus and windows. These are discussed at some length 
in (RAE 85a), and are summarized here to provide justifica- 
tion for the decisions we made. First, menus will be used 
because : 

(1) They do not require the user to memorize any (arbitrary) 
syntax or reserved words. 

(2) They encourage exploration. 

(3) They are feasible with fast screen updates. 

(4) They do not require much overhead. 

Windows will be used because: 

(1) They greatly increase the amount of information which 
can be displayed at one time by breaking it up into 
sections (this concept is explained in (IVE 82)). 

(2) They provide easy access to different levels of the 
program, since they can be easily shifted by the 
use of a mouse. 

D. DESIGN LAYOUT 

As stated earlier, HIPO diagrams were chosen as our 
design representation. The figures in Appendix A are those 
HIPO diagrams. They can be broken down as follows: 

(1) Figure 3.1 is the HIPO Table of Contents. It shows 
the hierarchical layout of the program and the 
numbering system which is used. 

(2) The remainder of the figures are grouped by module. 

They are identified by the number which corresponds 
to the module number in the HIPO Table of Contents. 



IV. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

There were two major conclusions reached during the 
research for (and the writing of) this thesis. They are 
both broad in nature and encompass several other findings. 

1 . GLAD is Necessary . 

Although there are numerous products on the market 
which address database problems, one cannot find any 
product which fill the requirements of descriptiveness, 
power, and ease of use and learning. These properties 
are absolutely necessary in today's environment, since 
there is an ever-growing diversity in database users. 

GLAD will provide these properties. 

2 . GLAD Can Be Done . 

There are many properties which must be incorporated 
into a database management system as was discussed in 
Chapter I. However, by a combination of incorporating the 
good properties of existing programs and designing new 
properties to meet the needs which have not yet been satis- 
fied, we can develop a program which should help today's 
workers to become highly successful database users. The 
design for such a program has now been accomplished. 
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B. RECOMMENDATIONS 



The implementation o£ GLAD represents the amount of 
work still remaining on this project. Much thought will 
be required during that phase, since many of the decisions 
(especially those of style) were left for that time. 

However, many ideas relating to the implementation pre- 
sented themselves during the design. The following list 
of recommendations is provided to the implementor to 
assist him by presenting some further study which will be 
necessary and some suggestions regarding those decisions 
which remain. 

1 . Help Fac il it ies /Error Messages . 

This aspect of a program is one of the most important 
(and often the largest). There is a fine line between 
providing enough help for the novice user and being a 
nisance to the experienced user. (An excellent discussion 
of prompts and error messages is contained in (DEA 82)). 

It will be important to devise a scheme which is regular 
(provides the same error message for the same type of mis- 
take) , robust (does not allow the user to become "hung" 
in a process with no escape), and appropriate (allows for 
different levels of help/error messages depending on the 
user's experience level). This design allows for such a 
scheme by providing a error-handling module which can be 
called by, and returns to, any point in the program. In 
addition, since a parameter is passed identifying the 
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calling module and the type of error, it will be very simple 
to provide identical error messages for similar errors. 
(Incidentally, this feature should also aid maintenance by 
enabling the maintenance programmer to identify the exact 
point of call for any error message) . 

2 . Use of Forms. 

There are several instances in the design where 
forms are used, such as the expand object form. These 
forms are used for two reasons. First, it separates the 
structure of the form from the remainder of the module to 
facilitate ease of implementation and maintenance. Also, 
it allows for flexibility in the implementation, whereby 
the implementor can easily adjust the structure of the 
forms to make them all as similar as possible (which, in 
turn, makes the program easier to use because it is more 
regular) . 

3 . Use of the Mouse . 

There is no module in the design which addresses 
the use of the mouse. This is because it is intended 
that standard library routines be used in implementing 
mouse operation. Again, the reason for this is to provide 
standardization in the operation of programs for the user. 

He needs to feel comfortable that he will be able to operate 
this program in the same manner as he does others. The 
use of standard library routines will allow that to happen. 
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4. User Access Levels. 



There is no mention in this design of access levels 
for database users. However, it is probable that any 
operational system will have the requirement of restricting 
access depending on the clearance level of the user. One 
example of such a need is the actual changing of data in 
the database. Naturally, one will not want to allow all 
users to change data values. This ability should be re- 
stricted to just a few people or billets. One recommenda- 
tion of how to provide this feature is a "login" process 
at the beginning of the session. Depending upon the 
clearance level of the person logging in, access to certain 
features of the program could be restricted. In fact, menu 
displays could be altered so that choices are not presented 
to users who are not authorized to choose them. 

5 . Number of Active Databases. 

As designed, the program recognizes only one active 
database. However, there is no reason that more than one 
database could be used, so long as the files used in queries 
are compatible. Such a capability would not affect the 
ability to keep the database themselves separate, but 
facilities would have to be added to determine where query 
sequences would be saved if requested (and others) . 

6 . Window Sizes. 

The screen percentage allocations made for the win- 
dows in this design were best-guess estimates of actual 
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requirements. They can be adjusted as necessary at the 
discretion of the implementor, based on more specific 
knowledge from empirical results or further research. 

It is also intended that the user be able to adjust the 
size of windows by the use of the mouse. There is no 
provision yet to allow him to change the permanent de- 
fault value of window sizes, but that may be another 
feature the implementor could add. There could be cir- 
cumstances, for instance, that a user would never have the 
occasion to use the query facility, but only browse the 
database. In this instance, it would be more beneficial 
to have a large schema display window at the expense of the 
result display window (without forcing the user to effect 
that change every time he uses the program) . 

6 . Use of Prototypes in Implementation. 

There is little discussion in this thesis regarding 
the order of module implementation. However, since this 
project is to produce a generally useful program (as 
opposed to an answer to a specific application), many of the 
features of GLAD will be evolutionary in nature. In fact, 
implementation of new features could continue indefinitely 
if desired. The consideration will be one of value versus 
time to implement. Because of this property, it would be 
beneficial to use prototyping in order to see which features 
are naturally important and which might prove superficial. 
One recommendation towards this goal is to implement the 
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basic screen display and windows first (with the use of 
dummy variables and modules where required) , then build 
from that point, one module at a time. This procedure 
would also aid the implementor in debugging and incremental 
testing . 

7 . Use of Color. 

This design is intended to be displayed on a mono- 
chrome monitor, but there are some advantages which could 
be gained on a color system. For example, different 
colors for different windows might help the user to focus 
on the most important part of the screen. There is one 
caution, however. It is very easy to overuse color to the 
point where the information is obscured. Any use of color 
should be carefully examined to ensure a positive contribu- 
tion results. 

8 . Implementation of Additional Related Packages. 

There are several possibilities for additional 

programs that could be used in conjunction with GLAD. 

One such program might be a chart/graph package. While the 
original implementor will not be able to undertake such 
additional challenges, he should certainly watch for such 
possibilities and guide his implementation so as to easily 
accept them. 
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APPENDIX 




Figure 3.1 HIPO Table of Contents (Main Modules). 
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Figure 3.2 HIPO Table of Contents (Utility Modules). 
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HIPO DETAIL DIAGRAM 
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HIPO NOTES 
for START (0) 



Step 1 Note 



1. The parameter "start" must be passed to 
sc r een - layout for the proper sub-module 
to be called 



2. Curr-defaults are contained in a file named 
curr-default-file. Items in the file include 
curr-menu, auto - res - show , db- sys -name , and 
any others which should be global to tlie 
program 

3. The initial set-up is now coraplete, so pass 
control to the administration menu m.odule. 



F igure 3 . 5 Start . 
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HIPO OVERVIEW DIAGRAM 
for DO- ADMIN (1) 
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HIPO NOTES 
for DO ADMIN (1) 



Step 


Note 


1 . 
3. 


The ADMIN Menu is displayed, but no selectio:. 
has been made. Execute a check- for- ir.nut loon 
until a mouse button is pressed. 

Allow the user to assure himself that he has 
saved/abandoned all changes 8 additions before 
quitting 



''^igiire 3.7 Do-Admin. 
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FROM: do-admin (1) 
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HIPO NOTES 
for OPEN-DB (1.1) 



Step Note ^ 

1, Throughout program, highlight action as it begins 
and return it to normal video when action is 
complete . 



2 . 



Header message may say "Select one of the following 
databases on file:" 



.3 . 



db-sys-name is one of the parameters which must be 
accessible at any time during program execution. 

The distinction is made here that curr-def aults is a 
set of global variables used throughout the program. 
This is not to be confused with curr-defaults-f ile , 
which is the file where the "per.manent values" of 
these variables are stored and is changed only by 
executing the setup_def aults module. 



Figure 3.10 Open-db 
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HIPO OVERVIEW DIAGRAM 
for CLOSE-DB (1.2) 
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HIPO DETAIL DIAGRAM 
for CLOSE-DB (1.2) 
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HIPO NOTES 
for CLOSE-DB (1.2) 



Step 


Note 


2 . 


It is not anticipated that any changes could remain 
unresolved (saved/abandoned) at this point of the 
program. This step is intended to be an "insurance" 
check . 


4. 


Permanent changes to the curr-defaults-f ile are only 
made in the setup-defaults module. 




Figure 3.13 Close-db. 
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HIPO OVERVIEW DIAGRAM 

£pr BROWSE (1.3 prep) 
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HIPO DETAIL DIAGRAM 
for BROWSE (1.3 prep) 
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HIPO NOTES 



for BROWSE (1.3 Prep) 



Step 


Note 




This preparatory module, and a similar one named 
Query in the BROWSE Menu, are included as "lead-ins” 
to the main menu control modules. Since we want the 
program to execute as efficiently as possible, we 
do not want the menu re-written every time a 
subordinate module returns control to the main menu 
control modules (do-admin, do-browse, do-query). 

The inclusion of these "prep" modules enables us to 
accomplish the initial set-up activities without 
having to repeat them. 



Figure 3.16 Browse. 
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HIPO OVERVIEW DIAGRAM 

or DO- BROWSE (1.3) 
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HIPO DETAIL DIAGRAM 
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HIPO NOTES 
for DO-BROWSE (1.3) 



Step Note 



3. If we got past step 2, the only valid choice was 

"quit", which returns us to the ADMIN Menu control 
module. If "quit" is not the selection at this 
point, there was a mistake in the input, so output 
an error message and return to the top and let the 
user try again. 



4-7. 



The remainder of the steps perform a "prep" function 
for do-admin (1). We cannot call start (0) to do 
this since start (0) also does program initiation, 
such as loading Curr-def aults . 



Figure 3.19 Do-browse. 
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HIPO DETAIL DIAGRAM 

for SETUP-DEF (1.4) 
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HIPO NOTES 
for SETUP-DEF (1.4) 
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HIPO OVERVIEW DIAGRAM 

for AD-HELP (1 . 5) 
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HIPO DETAIL DIAGRAM 
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HIPO NOTES 
for AD-HELP (1 . 5) 



Step 


Note _ 


3. 


This module is currently designed to provide a 
simple list to the user. Each menu item is de- 
scribed along with the types of actions which will 
be required of the user. It might be more useful 
to prompt the user for a menu item he wants de- 
scribed, and present only that item. Or, better 
yet, allow the user to choose the "help" option 
anywhere during the execution of the menu or sub- 
menu items, and provide very specific guidance re- 
garding the actions expected of the user at that 
point . 

Deciding which of the first two methods to design 
was simply a matter of personal style. 

A decision to use the last method should be made 
only after much deliberation, because it implies 
that a help message be prepared for every possible 
user situation (very difficult indeed). 

Any keystroke can be used here to symbolize com- 
pletion. I recommend that the particular symbol be 
chosen to coincide with the one used on the imple- 
mentation system to indicate a "continue" selection. 



Figure 3.25 Ad-Help (1.5) 



76 



HIPO OVERVIEW DIAGRAM 




to 



PQ 

O 

I 

oi: 

u 

CO 

cu 

c 

o 




0 

1 

u 

in 

CD 

Q 



O 

C\J 

to 

0) 

D 

CO 

•H 

CL, 



77 










^r- 








in 05 


CO o5 








+-> r-H 


H «-H 




1 




tH CU CO 


iH Pl. 


CO 




H 


D C 


:3 CO 




&0 


&. 


05 *H 'H 


03 *H 


•H 


0 'H 


s 


"d H 


^ nj 


+-> 


.Q X 


O 


0 X 


0 


X 


•H 




nd nj co”:3 


T5 T5 05 


CiOnJ 


?H +J 0 


& 


0 1 S ‘H 0 


0 « B 


•H 0 


U U +-> 




+j ^ 0 .— 1 > 


+j ?-• 0 


«-H > 


(/^ 0 X 




05 ^ ^ ^ O 


OJ ?H X 


X o 


0 *1 — k CO 


0 


n:D D u CO S 


T5 D O 


‘ CO S 


nd ^ -H 


in 


L> CO -H 0 


C- U CO 


•H 0 


“ O r-H 


D 


o 1 1 :r 


O 1 • 


n:: 























•H 






CNJ 






K5 


CO 0 






















/- — \ '■ — ' 






• 


+J 0 
















"T3 






tn 






1— 1 


•H CO 
















0 






• +-> 






'■ — ' 












O 






rH 






.-H D 








0 4-> O 










0 






rH 






o 






0 


P CO U H 










"T3 






•H 






>^ 






CO 


CP P3 0 










•H 












0 05 






:2 


0 •»—»+-> 




rv 






> 






' 






CO rH 






o 


£ CO 




"Td 




rsi 














^ 1 








+-> O -H 




0 




PD 


I— 1 




CNJ 


B 






O G 








C CJ rH 








— ' 


05 








rH 




^ 0 






1 


•H 0 C4-( 




• H 






B 




w +j 


O 


05 




0 






o 


•r— i O t->T5 




•r— ^ 


c5 


?H 




CJ ^-t 


B 




1 ^ 




/ N 






0 


u 


B 


o 


0 


05 0 


1 






O 0 


•r— j 


S >H 




O O 0 o 




in 


O 


0 


c 


CO 


B *1-^ 


•«-H 


O 




"Td CO 




2 • 


• • 


B ' 


•H 


0 


1 






t— 1 


<D JP rCi 


C 






o 


Ph^O 


2 


C 05 






u 


o 


0 


X o 


O 








1 


O • 


O 


r 05 C O 


U 




u 


CO 


+-> 




o 


1 


O 




• • 




^1— 1 


Pu 


+-> CO 


CO 


CO CO 


1 




/ — \ T-5 


> in in 




+-> 




o 


u 




Cm 


u c: ?-• 0 


0 


c 


0 




c 


ro Xi 


1 ’H 


u 




/ s 


£-• 


CO 


Q 




0 O O nd 




•H "13 


05 




• O 




in 


z 


K5 




0 






•r— k Hi 1 




0 


1 




U 


I— 1 1 


05 +-> 


0 


+-> 


• 




Q 



HO 

< 



0) u 

C, 0) 









0 



O ^ 
o in 



'T3 /— N u 
O 0 
c3 



E-*P^ 


0 


O 


CO 


U 


0 


"Td 


u 


+-> 




O 


CO 


0 




•H 




C 


Q 




0 


CNJ 


WU 


Q 


•H 






Q 


05 












"Td 


H 


:2 


05 


• rH 


O 




CO 


. 


Qc/: 


• H 


+-> 




CO 




0 


B 


O 


05 


0 


o 


1 


P5 




• H 










K5 


w 


U 


•H 


+J 


C 


>> 


, ^ 


O 


>N 


B 


Q 






O 


05 


> 


0 


0 




O 




OQ 


o 


CO 


Q 


•H 


"Td 


rH 




05 


0 


•H 


Q 




>N 


B 




H 


Q 




U 


0 


Q 


in 


o 


B 


05 


o5 


05 


H 


rH 




5m 


1 




05 


0 


"Td 


05 


•H 




rQ 




H 


0 


Q 


< o 


CO 


0 






1 


73 


U 


O 


0 


rH 


q: 


0 


•H 






1 


P5 


Q O 


"T3 






05 




CO 


0 


fP 


CO 


CO 


"Td 




1 


u 


"Td 


5m 


U 




o 


CO 


Hi 


c 


CO 


Q 




rH 


•H 


B 


0 




0 




o 


C 


CO 


c 


Q 


CO 




"O 


•H 






•H 




0 


05 




05 


0 




"Td 


o 


+-> 


0 




05 


O 


0 










+-> 




0 


B 




+-> 


fP 




05 


z 


H 




0 


12 


Q 




"Td 




o 








0 


CO 


05 


CO 


u 




u 


5m 






0 




05 


X 


Q 


z 




H 






CO 


CO 


rH 


C 


•H 


0 


0 


CO 


"Td 


C 


c 


s 


o 


5m 


0 


Q 












♦H 


P5 


0 






•r-> 


H 




0 




u 


05 


CO 


"T3 




05 






5d 






rH 


O 






+-> 


Q 


0 


rH 




D 


o 


C 




0 


CO 






o 


5m 








s 


0 


U 


•H 


O 


rH 


rH 




+-> 


+-> 




rH 


5m 


c 


q: 


P5 


0 


D 






CO 




B 


0 






0 


05 


o 


0 


0 


"Td 


rH 




•H 


+-> 


+J 


"Td 


+-> 






•H 


H 


05 


q: 


H 


H 


Q 


U 




Q 


Q 


"Td 


o5 


O 


0 


•H 


0 


• H 


0 






X 


h-H 


G 


u 


•H 


HH 












< 


O 




Q 


:2 


cp: 


> 








. 


. 




. 




. 


05 


Q 




U 


"Td 


. 


. 








• 




. 






rH 


CNJ 




K5 
















LO 


vO 












GO 





CO 


CO 


CO +j 


+-> 


+-> 


4-> P 


rH 


rH 


rH O 


0 D 


P5 


a 


CO o5 


05 


o5 o5 


a H 


H 


H rH 


O 0 


0 


0 1 


e H "Td 


"Td 


"Td p 


\ P5 1 


1 


» 0 


5m 5h 




U 0 


O c U 






CO HH ;3 


P5 


D o 


X U 


U 


u CO 



ro 



P:^ 

W 

P3 

s: 

D 

2 

X 

o 

OQ 



78 



HIPO NOTES 

for DESCR-OBJ (1.5.1) 



Step 


Note 


3. 

4-8 

4-6 


Curr-descr-obj is a list of objects which are being 
described in the schema presentation. 

This "describe object" selection should act as a 
toggle for each object. If the object is not being 
described, selecting "describe object" will cause it 
to be described. Conversely, if it is already being 
described, this selection causes the description to 
be cancelled and the schema to be rewritten without 
it 

The method of display for an object description is 
as follows: 

-> use a small window format which will overwrite 
the object in the schema display 
-> this window will have standard boxes which will 
be filled in from information in the object 
file, such as name, fields, etc. 

This action is actually performed in the screen- 
layout module, but is introduced here for clarifica- 
t ion . 



Figure 3.28 Descr-Obj 
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BOX NUMBER: 



HIPO NOTES 



for UPDATE-OBJ (1.3.2) 



Step 


Note 


3-4 . 

5. 


This display and edit function should be done in a 
standard edit format that the normal user would be 
familiar with. It is not necessary to have an elab- 
orate editor since this is not the primary function 
of the program, but it should be effective and 
understandable . 

Save and Abandon should be small icons located in 
the top corners of the misc-window. By having them 
displayed there, the user will always be comfortable 
that he knows how to end the update function at any 
time (and for any reason for the "abandon" option). 



Figure 3.31 Update-Obj (1.3.2) 
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HIPO NOTES 

for PRINT-OBJ (1.3.3) 



Step 


No t e 


2. 


This sub-menu is actually composed of just the 
three choices printed out on the line immediately 
below the menu box. 


4. 


Deciding whether the mouse is positioned on one of 
the items entails noting the curser position at the 
start of each choice and counting spaces 




Figure 3.34 Print-Obj (1.3.3) 
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HIPO OVERVIEW DIAGRAM 

for SCREEN- DUMP (1.3.3. 
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HIPO DETAIL DIAGRAM 

for SCREEN- DUMP (1.3.3 
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HIPO NOTES 

for SCREEN- DUMP (1.3. 3.1) 



Step 



2 . This 
such 
level 



Note 



header message will probably inc 
as database name, current date, 
(if used) 



lude things 
and user access 



4. 



6 . 



It is anticipated 
to print what the 
this option which 
paper 



that the user will usually want 
schema looks like, so we give him 
will be quicker and use less 



In this, and the two following PRINT sub- items, 
highlighting is turned off in a module that does 
not turn it on. While this is usually not a de- 
sirable characteristic, in this case it is justified 
since the modules and logically connected and it 
speeds execution 



Figure 3.37 Screen-Dump 
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HIPO OVERVIEW DIAGRAM 

for PRINT-OB (1.3. 3. 2 
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HIPO DETAIL DIAGRAM 

or PRINT-OB (1.3.3.: 
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HIPO NOTES 





for PRINT-OB (1.5. 3. 2) 


Step 


Note 


1. 


The object name can be typed in, or the user can 
position the mouse over the desired object and 
press the "select" button. 


3. 


The number of field names (and table values) to be 
printed will be determined by the width of the 
fields in the records and the width of the platen 
on the printer. Stop at the last field name (and 
value set) which will fit completely. 




Figure 3.40 Print-Ob 
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HIPO DETAIL DIAGRAM 
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BOX NUMBER: 



HIPO NOTES 

for PRINT-REP (1.3. 3. 3) 



Step 



3. All fields 

Otherwise , 
is . 



Note 



in report form must exist 
you cannot know where the 



in the object, 
inconsistency 



5. 



This will be done as indicated in the report form 
directives (i.e. the header, field names, and 
widths will be specified) 



Figure 3.43 Print-Rep 



HIPO OVERVIEW DIAGRAM 





(D 

;3 

cy 



to 

(D 

D 

tJO 

•H 

PL, 



95 



HIPO DETAIL DIAGRAM 
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HIPO OVERVIEW DIAGRAM 
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HIPO NOTES 
for DO-QUERY (1.3.4) 



Step 



Note 



The call at the end of this module is different 
than the one at the end of do-browse (1.3). The 
reason is that do-browse has a simple lead-in 
module that can be used (recall that the lead-in 
module to do-admin is start (0) which does more 
than simply change the menu display and the curr- 
menu variable) . 



Figure 3.48 Do-Query. 
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HIPO NOTES 

for EXPAND-OBJ (1.3.5) 



Step 



Note ; 

This module should be implemented in a manner almost 
identical to that used for descr-obj . They are 
similar functions, so they should look very similar. 
The only difference between the two modules is the 
actual layout of the forms (small windows) that will 
overwrite the schema during screen- layout (draw- 
schema) . 



Figure 3.51 Expand-Obj . 
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HIPO DETAIL DIAGRAM 
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HIPO NOTES 
for LIST-MEM (1.3.6) 



Step 


Note 




This module is the third in the series of object 
"expansion" options. It should be implemented 
the same way as the other two (descr-obj and 
expand-obj). The use of "forms" in all three of 
these cases should simplify their implementation 
and enable the implementor to achieve conformity 
and regularity in their use. 



Figure 3.54 List-Mem. 
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HIPO DETAIL DIAGRAM 
or CONTER-OBJ (1.3.7) 
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HIPO NOTES 

for CENTER-OBJ (1.3.7) 



Step 


Note 




This module is fairly straightforward except for 
the case in which the user wants to get out of 
having the schema display centered around any 
object. There are two ways to accomplish this; (1) 
the user selects "center object" without having the 
mouse positioned on any object, and presses 
"carriage return" when prompted for an object name 
or (2) the user selects "center object" without 
having the mouse positioned on any object, and 
types a symbolic name (such as "home" or "none") 
when prompted for an object name. The advantage to 
option (1) is that it is faster and easier. The 
advantage of option (2) is that it precludes the 
user from "accidentally" selecting the "none" 
option. However, he would need to be reminded of 
the symbolic name for "none", because we certainly 
do not want to force him to memorize an arbitrary 
command code. The choice between the two options is 
really one of style, since either would accomplish 
the task. 



Figure 3.57 Center-Obj . 
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FROM: do-browse (1.3) 
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HIPO DETAIL DIAGRAM 
for SAVE-RES (1.3.4 
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HIPO NOTES 

for SAVE-RES (1.3. 4.1) 



Step 


Note 


2. 

4. 


The query sequence to be saved here is one of the 
sequences the user created himself earlier by se- 
lecting "create result". It is important to note 
here that the result itself may not have been 
created at all, and all we are dealing with here is 
the sequence that creates the result. 

This PB-file-list is a list of file names that con- 
tain certain query sequences, repetitive actions, or 
command "programs" that the user or database admin- 
istrator has created. These are included to make 
the program eas ier/faster to use for the experienced 
user, and perhaps easier to learn for the novice 
user (in the case where the database administrator 
creates command programs). 



Figure 3.63 Save-Res. 
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HIPO OVERVIEW DIAGRAM 

for SHOW- RES (1.3. 4. 2 
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for SHOW- RES (1.3.4.: 
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HIPO NOTES 

for SHOW-RES (1.3. 4. 2) 



Step 


Note 


6. 


This instruction may prove to be tlie most time- 
consuming of the entire program. Until this time, 
the result has not actually been formed: only the 
query sequence has been saved. Now it is necessary 
to actually execute that sequence. 


7. 


The show-res-form to be used here will be essential- 
ly identical to the one used for list members. The 
difference is that it is to be displayed below the 
result box rather than overwriting it as we did 
with list-mem. The reason we do not want to lose 
the information content provided by its shading. 
(Recall that the result box and all objects used 
to generate the result are identically shaded.) 




Figure 3.65 Show-Res. 
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TO: do-query 
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HIPO NOTES 





for CLEAR-RES (1.3. 4. 5) 


Step 


Note 


3 . 


This result-file is the one created by create-res 
and includes filenames and query sequences. The 
"X" refers to the integer used by the numbering 
system for that particular result sequence. 


4. 


This ob j - shade - 1 ist is the objects which were used 
in the result formulation. It is referenced by the 
particular result sequence. 




Figure 3.68 Clear-Res. 
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HIPO NOTES 

for CREATE-RES (1.3. 4. 4) 



Step Note 

2. This step will result in a file 

the steps previously identified 



which contains all 
by spec-obj 



This creates/adds to a list of results which the 
user has created during this session. It will be 
used to determine how many results are shown in the 
schema display, along with other user options, such 
as save/show/clear result. 



Once the new file has been created, all current 
entries in specify-file are cleared so the user 
can begin his next query formulation. 



Figure 3.71 Create-Res. 
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HIPO NOTES 



for COMB- RES (1.3. 4. 6) 



Step 


Note 




This module is essentially the same as create-res 
except that it takes the steps previously defined 
for multiple queries and combines them into one 
larger query. Because of that, there are several 
"house-keeping" steps to straighten out the files 
abd schema display. 



Figure 3.76 Comb-Res. 
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HIPO NOTES 

for SPEC-OBJ (1.3.4. 7) 



Step Note 



3. The commands are not given here for the QBE query 

formulations. Specific information has not yet 
been received to provide complete guidance, but 
such information should be in hand before proceed- 
ing with query rules/codes to ensure consistency. 



5. 



This file contains a 
specify- info-X files 
the result. 



list of the names of the 
which will be used to create 



Figure 3.79 Spec-Obj . 
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screen - layout (U2) 



HIPO NOTES 

for CREATE-REP (1.3. 4. 9) 



Step 


Note 


3. 

7. 


This module should be implemented in a manner very 
similar to update-obj (1.3.2). It should have a 
standard form displayed that the user can fill in 
with his parameters. 

This report-file is a file containing the names of 
reports the user has previously created. 

The save/abandon option only affects current work. 
That is, it cannot be used to call up a previously 
defined report form and erase it. There should be 
some device implemented in the form to allow delet- 
ing a report file. 



Figure 3.84 Create-Rep. 
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HIPO DETAIL DIAGRAM 
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HIPO OVERVIEW DIAGRAM 
for ERR-MSGS (Ul) 
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HIPO DETAIL DIAGRAM 

for HRR-MSGS (Ul) 
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BOX NUMBER: Ul 



HIPO NOTES 
for ERR-MSGS (Ul) 



Step 


Note 


1 . 

2. 
4 . 


This input parameter should indicate a coding 
scheme which will identify the class of error 
message, and the particular error message within 
that class. By using such a scheme, locating the 
message will be simplified, messages can be shared 
by many modules, and the message contents can be 
standardized (i.e. the same type of error anywhere 
in the program will get exactly the same error 
response) . 

By using a well-devised coding scheme, the search 
technique to find a particular entry should be 
trivial . 

Forcing the user to press Carriage Return (or any 
other symbol) to continue implies that we have a 
novice user that must be led through the process. 
This may not be necessary, and may annoy the 
sophisticated user. This is really a question of 
personal style, though, and can be altered if 
desired. In fact, one could provide a default op- 
tion of "Help me through" or "Leave me alone." 

Another important point to note here is that this is 
the first module which returns to the point of call 
rather than simply calling another module. By this 
1 mean that you must return to the step within the 
calling module rather than the module itself. 



Figure 3.89 Err-Msgs. 
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HIPO OVERVIEW DIAGRAM 

for SCREEN-LAYOUT (U2) 
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HIPO NOTES 

for SCREEN-LAYOUT (U2) 



Step 


Note 


1. 

2. 


This simple case statement uses the input parameter 
to determine which sub-module should be called 

This module, like err-msgs (Ul) , must return to the 
particular point of call within the calling module 

From a strict efficiency point-of-view, this module 
is not necessary at all. The reason it has been 
included is that it increases program clarity by 
providing a single module to interface with the 
rest of the program. Since this project is being 
accomplished by more than one person, we do all that 
is possible to ensure clear meaning and methodology. 



Figure 3.92 Screen- Layout . 
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HIPO OVERVIEW DIAGRAM 
for DRAIV-SCREEN (U2.1) 
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HIPO DETAIL DIAGRAM 
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HIPO NOTES 

for DRAW- SCREEN (U2.1) 



Step 


Note 




All parenthesized numbers in this module are based 
on the percentage of the screen that the associated 
box or window will take. The first number is the 
percentage of standard text rows, the second number 
is the percentage of standard text columns. These 
can, however, be adjusted as necessary during imple- 
mentation. In fact, some of the curr-defaults could 
be current window sizes which could be saved for 
future use. 

There are three types of drawings to be made by this 
module. The differentiation is as follows : (l)boxes 
or things which are not intended to be changed. The 
information which will be displayed in the boxes 
should fit and there is no reason that the amount of 
information will change. Boxes are used for menus. 
2)windows must be much more flexible. They are drawn 
with elevator bars along the bottom and right side 
to show the user the percentage of information in 
the file which is currently being displayed. Their 
size may also be changed by using the left "drag" 
button of the mouse (this brings up the issue of 
whether this change will remain after the current 
operation or not). Windows are used where varying 
amounts of information will be displayed, such as 
the schema, 3)lines are really miniature boxes. 

They will display or accept only one line of 
information. Lines are used for commands and 
reminders . 



Figure 3.95 Draw-Screen. 
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HIPO OVERVIEW DIAGRAM 

for DRAW-SCHEMA (U2.2) 
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HIPO DETAIL DIAGRAM 
for DRAW- SCHEMA (U2.2) 
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HIPO NOTES 

for DRAW- SCHEMA (U2.2) 


Step 


Note 


1. 


This schema-diagram has already been generated for 
us in the data definition portion of the program. 

It was built as the database administrator designed 
the database system. All we have to do here is dis- 
play it. 


2 . 


These forms are small windows (with varying amounts 
of information) which will overwrite the object with 
which they are associated. The way they should be 
implemented is by a standard form which goes to the 
file it represents and pulls out the required infor- 
mation to display. It may be a good idea here to 
save this information the first time it is retrieved 
and use it each time this module is called provided 
that it has not been changed (by update-obj ) . 


3 . 


The same comments as step (2) apply to this step, 
especially the one about saving the information 
required to perform this step. In show-res, this 
is where the data manipulation is actually performed, 
so it is imperative not to have to rediscover the 
wheel each time it is ued. 




Figure 3.98 Draw-Schema. 
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HIPO OVERVIEW DIAGRAM 

for DRAW-ADMENU (U2.3) 
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HIPO DETAIL DIAGRAM 
for DRAW-ADMENU (U2.3) 
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Figure 3.100 Draw- Admenu . 



HIPO NOTES 

for DRAW-ADMENU (U2.3) 



Step 


Note 




This module (and the following two) simply write the 
menu items in the menu-box. It is, however, impor- 
tant to note the boundaries of each item's small 
box because the user can select the item with a 
click of the mouse and the program must be able to 
tell if he is in a menu item box when the mouse is 
clicked . 



Figure 3.101 Draw-Admenu. 



152 



HIPO OVERVIEW DIAGRAM 
for DRAW-BRMENU (U2.4) 
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Figure 3,102 Draw-Brmenu. 



HIPO DETAIL DIAGRAM 
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HIPO OVERVIEW DIAGRAM 
for DRAW-QUMENU (U2.5) 
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HIPO DETAIL DIAGRAM 
for DRAW-QUMENU (U2.5) 
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HIPO DETAIL DIAGRAM 
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screen-layout (U2) 



HIPO NOTES 

for ERASE-MENU (U2.6) 



Step 


Note 




The three "erase modules" are used to blank out the 
previous contents of a box/window. The reason that 
they all are defined by the "boundary" of the sub- 
ject area rather than specific positions on the 
screen is that the boundaries of the areas to be 
erased can be altered by the use of the left "drag" 
mouse button, so you must make sure the entire 
area gets erased, not just the area initially 
defined by the program. 



Figure 3.108 Erase-Menu. 
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HIPO OVERVIEW DIAGRAM 
for ERASE-SCHEMA (U2.7) 
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HIPO DETAIL DIAGRAM 
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HIPO OVERVIEW DIAGRAM 
for ERASE-MISC (U2.8) 
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HIPO DETAIL DIAGRAM 
£pr ERASE-MISC (U2.8) 
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